Describe your changes

Add .github/workflows/docs.yml — a GitHub Actions workflow that
automatically builds and deploys MkDocs documentation to GitHub Pages.

Workflow behaviour:

• Triggers on push to main and on pull requests targeting main
• Sets up Python 3.10 and uv
• Installs docs dependency group (mkdocs, mkdocs-material,
  mkdocstrings[python])
• Builds docs with mkdocs build --strict (fails CI on any warning)
• Deploys to GitHub Pages via mkdocs gh-deploy only on merges to main

This builds on top of the MkDocs structure added in #457.

Issue Link

closes #461
relates to #61

Type of change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 📖 Documentation (Addition or improvements to documentation)

Checklist before requesting a review

• My branch is up-to-date with the target branch
• I have performed a self-review of my code
• For any new/modified functions/classes I have added docstrings that clearly describe its purpose, expected inputs and returned values
• I have placed in-line comments to clarify the intent of any hard-to-understand passages of my code
• I have updated the README to cover introduced code changes
• I have added tests that prove my fix is effective or that my feature works
• I have given the PR a name that clearly describes the change, written in imperative form
• I have requested a reviewer and an assignee

Checklist for reviewers

Each PR comes with its own improvements and flaws. The reviewer should check the following:

• the code is readable
• the code is well tested
• the code is documented (including return types and parameters)
• the code is easy to maintain

Author checklist after completed review

• I have added a line to the CHANGELOG describing this change:
  • added: GitHub Actions workflow to build and deploy MkDocs docs to
    GitHub Pages

Checklist for assignee

• PR is up to date with the base branch
• the tests pass
• (if the PR is not just maintenance/bugfix) the PR is assigned to the next milestone. If it is not, propose it for a future milestone.
• author has added an entry to the changelog (and designated the change as added, changed, fixed or maintenance)
• Once the PR is ready to be merged, squash commits and merge the PR.